Control system apparatus and systems based thereon that transfer control apparatus information over IP networks in web page-less transfers

ABSTRACT

A system for process control comprises a server digital data processor and a client digital data processor that are coupled by a network, such as the Internet or an Intranet. The server digital data processor, which is additionally coupled to a control/sensing device and any associated interface equipment (collectively, referred to as “process control apparatus”), includes a command processor that transfers information between the network and the process control apparatus. The client digital data processor includes an information client (e.g., a so-called Internet web browser) capable of requesting and receiving an applet from the server digital data processor. The information client, further, defines a hardware-independent and operating system-independent virtual machine environment within the client digital data processor. The client digital data processor executes, within that virtual machine environment, an applet for configuring the client digital data processor as a “process controller” that establishes communications over the network with the command processor and that monitors and/or controls the process control apparatus via those communications.

BACKGROUND OF THE INVENTION

The invention pertains to process control and has application to remoteprocess control.

Process control refers to the control of the operational parameters of asystem by monitoring one or more of its characteristics over time. It isused to insure that the quality and efficiency of the system remainwithin desired parameters over the course of time. While process controlis typically employed in the manufacturing sector for process,repetitive and discrete manufactures, it also has wide application inservice industries, such as environmental control.

Process control equipment typically utilizes control/sensing devicesthat are physically integrated into the systems being controlled. Forexample, a thermostat is typically used in environmental control toinsure that building temperatures remain within specified parameters.Likewise, flow control sensors and automated valves are typically usedin process manufacturing to insure proper fluid flow volumes.

Though in early process control systems, control/sensing devices weretypically stand-alone units, modern process control systems providecentral workstations for monitoring and controlling the control sensingdevices. Particularly robust systems are the I/A Series industrialautomation systems designed, manufactured and marketed by the assigneehereof, The Foxboro Company, of Foxboro, Mass., USA. In these systems,multiple control/sensing devices are coupled by way of buses to controlstations which, in turn, are coupled by way of a local area network(LAN) to one or more operator workstations.

The I/A Series systems are built around the client/server model. Clientapplications software executing on the workstations exchange informationwith the control/sensing devices via a server, referred to as the“object manager,” executing in distributed fashion in the controlstations. Upon request by a client application, the server creates,locates, accesses and updates data structures (“objects”) storinginformation on the status of at least selected control/sensing devices.For example, a client application that displays temperatures sensed by athermocouple requests that the server create an object storing atemperature reading from the thermocouple and that the server notify theclient each time the temperature changes.

Although modern process control systems, such as the I/A Series systems,have proven quite successful, to date they have provided only limitedremote access capabilities. Thus, while numerous operator workstationsmay reside within the factory or facility in which the control/sensingdevices are disposed, it has traditionally proven difficult to accessand control those devices outside those areas.

Remote access and control of processes is desirable for a number ofpurposes. A plant manager who is “on the road,” for example, may wish tomonitor the plant processes while travelling. By way of further example,the manufacturer of process control equipment may require remote accessto a plant's control/sensing devices in order to provide technicalsupport.

An object of this invention is to provide improved methods and apparatusfor process control.

Another object of the invention is to provide such methods and apparatusas permit monitoring and control of remote processes.

Still another object of the invention is to provide such methods andapparatus as can be readily adapted to existing automated processcontrol systems.

Yet still another object of the invention is to provide such methods andapparatus as can be implemented without undue expense and without undueconsumption of resources.

SUMMARY OF THE INVENTION

The aforementioned objects are among those attained by the invention,which provides, in one aspect, a system for process control comprising aserver digital data processor and a client digital data processor thatare coupled by a network, such as the Internet or an Intranet. Theserver digital data processor, which is additionally coupled to acontrol/sensing device and associated interface equipment (collectively,referred to as “process control apparatus”), includes a commandprocessor that transfers information between the network and the processcontrol apparatus.

The client digital data processor includes an information client (e.g.,an Internet web browser) capable of requesting and receiving an appletfrom the server digital data processor. That information client,further, defines a hardware-independent and operating system-independentvirtual machine environment within the client digital data processor.

The client digital data processor executes, within that virtual machineenvironment, an applet that configures the client digital data processoras a “process controller” that establishes communications over thenetwork with the command processor and that monitors and/or controls theprocess control apparatus via those communications. The applet isintermediate or executable code that is suitable for interpretation orexecution within the virtual machine environment and that ishardware-independent, operating system-independent and windowssystem-independent

In further related aspects, the aforementioned applet can be, forexample, JAVA programming language bytecode, and the virtual machineenvironment can be that created by a JAVA-enabled web browser.

According to other aspects of the invention, the command processor in asystem for process control as defined above provides services (i.e.,“software services”) for access and modification of informationregarding the process control apparatus. These services can permit, forexample, the creation of a data structure object that stores informationabout the process control apparatus and that associates a name with thatobject; the destruction of such an object; the accessing of informationin such an object; the updating of information in such an object; thedetermination, from an object name, of the physical address of theobject; and the notification of changes in information stored by theobject. The process controller generates and transmits over the networkto the command processor requests for such services in order to monitorand/or control the process control apparatus.

A further aspect of the invention provides a system as described abovein which the process controller generates and transfers commands (e.g.,requests for service) over the network to the command processor in orderto effect a transfer from the command processor of information regardinga status of the process control apparatus. The command processorresponds to those requests by generating information on the status ofthe process control apparatus and transferring it back to the processcontroller over the network. The process controller can, for example,generate a user display based on that information.

In a related aspect, the command processor responds to selected commands(i.e., requests for event-driving access) by notifying the processcontroller of changes in the status of at least selected aspects of theprocess control apparatus. By way of example, where the process controlapparatus includes a thermocouple, this aspect of the invention permitsnotification of the command processor whenever the thermocouple senses achange in temperature that exceeds a predetermined delta value.

Still further aspects of the invention provide process control systemsas described above in which the server digital data processor includesan information server (e.g., a hypertext transfer protocol server). Aninformation client (e.g., web browser) in the client digital dataprocessor establishes communications with the information server overthe network and receives therefrom a hypertext markup language (HTML)document referencing the applet. The web browser generates a userdisplay of that document and, in response to a user command, transfersto the information server a request for the applet.

Yet still further aspects of the invention provide systems for processcontrol in which a first digital data processor executes a JAVA appletwithin a virtual machine environment defined on the digital dataprocessor. The applet configures the digital data processor to generatea message to invoke a method in connection with monitoring and/orcontrolling a process control apparatus. An object manager, which is incommunication with the JAVA applet, responds to the message for invokingthe method.

Other aspects of the invention provide methods for process controlparalleling the operations of the systems described above.

These and other aspects of the invention are evident in the drawings andin the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the invention may be attained by reference tothe drawings, in which

FIG. 1 depicts a system for process control according to the invention;and

FIG. 2 is an event trace diagram depicting messages that flow among thecomponents of the system of FIG. 1 in an embodiment for graphing tendsin process control apparatus data values.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT

FIG. 1 depicts a system 10 for process control according to theinvention. The system includes client digital data processors 12, 14 andserver digital data processor 16. The digital data processors 12, 14, 16are connected to one another via network 18.

Server digital data processor 16 is, additionally, coupled to processcontrol apparatus 19 a-19 e via bus/network structure 30 and controlstations 23 a-23 e, as shown. The process control apparatus includeconventional control/sensing devices, which are shown in theillustration as flow control valves, and associated interface equipment,which are marked “FBM” in the illustration. The process controlapparatus 19 a-19 e are intended to represent any conventionalcontrol/sensing devices and interface equipment of the typeconventionally used to monitor and control processes—including, by wayof non-limiting example, continuous, repetitive and discrete processes,and environmental control processes, among others.

As discussed below, control stations 23 a-23 e include objects storinginformation that control, and reflect the status of, their associatedprocess control apparatus 19 a-19 e. The control stations 23 a-23 e alsoexecute object management software (marked “OM”) that manage and overseeaccess to those objects. The control stations 23 a-23 e are of the typeconventionally used in a distributed process control architecture.Preferred such control stations are commercially available from theassignee hereof, The Foxboro Company, as part of its I/A Seriesindustrial automation systems.

The digital data processors 12, 14, 16 comprise conventional digitaldata processing systems of the type commercially available in themarketplace. Though client digital data processors 12, 14 areillustrated as a portable computer and a personal digital assistant,respectively, those skilled in the art will appreciate that these maycomprise other computing systems, such as desktop computers andworkstations, as well. The digital data processors 12, 14, 16 may becoupled to the network 18 directly, as shown, or other networks (e.g.,LANs and WANs), routers, or interface servers (not shown).

The network 18 comprises any conventional digital data processingnetwork (e.g., LAN or WAN), cable television-based network, wirelessnetwork and/or any telecommunications-based network capable ofsupporting communications between server digital data processor 16 andclient digital data processors 12, 14. The network 18 preferablycomprises the global Internet and/or an enterprise-based Intranetsupporting communications via the TCP/IP protocol (i.e., the currentstandard protocol of the Internet). Utilization of networks supportingthis protocol is advantageous insofar as it permits the use ofcommercially available products (such as web browsers, discussed below)in components of the illustrated embodiment. Those skilled in the artwill appreciate that the invention is applicable to networks supportingother protocols, as well.

The digital data processors 12, 14, 16 execute software thatrespectively configure them for communication over the network 18. Forexample, they execute protocol stacks and other software that permitthem to establish and carry out communications utilizing the TCP/IPnetwork protocol. In addition, they execute information client/serversoftware that configures them to carry on high-level communications,particularly, over the Internet.

More particularly, in the illustrated embodiment, server digital dataprocessor 16 includes information server 20 responsible for establishingcommunications over network 18 with information clients executing on theclient digital data processors 12, 14.

The information server 20 is preferably a hypertext transfer protocol(HTTP) server capable of transferring markup language information and,particularly, hypertext markup language (HTML) documents, to the clientdigital data processors 12, 14. In alternative embodiments of theinvention, information server 20 can comprise any other such servercapable of supplying an applet to the client digital data processors 12,14 in response to requests by them.

The information server 20 establishes communications with the clientdigital data processors 12, 14 and, particularly, their respectiveinformation clients in the conventional manner known in the art. Oncecommunications are established, the information server transfers to theinformation client an applet that executes within the virtual machineenvironment and that monitors and/or controls the process controlapparatus via communications with a command processor in the serverdigital data processor 16, as discussed below.

The client digital data processors 12, 14 include information clients22, 24, respectively, that are responsible for initiating and conductingat least preliminary communications with the server digital dataprocessor 16 over the network 18. The information clients 22, 24,particularly, (1) initiate communications with the information server 20over the network, (2) request and receive from the information server 20an applet, and (3) define a platform-independent (i.e., ahardware-independent, operating system-independent and windowsystem-independent) virtual machine environment within the respectiveclient digital data processor 12, 14. Such information clients are, inone embodiment, JAVA-compliant web browsers including the HotJavabrowser from Sun MicroSystems, Inc., NetScape Navigator from NetscapeCommunications Corporation, and the Internet Explorer from MicrosoftCorporation.

As used herein, an applet is intermediate or executable code suitablefor interpretation or execution within the virtual machine environmentand that is hardware-independent, operating system-independent andwindows system-independent. Preferred applets are in the form of Javabytecode of the type generated by the Java language compiler availablefrom Sun Microsystems, Inc.

The aforementioned preferred web browsers define a preferred virtualmachine environment comprising the Java programming language run-timeplatform and Java interpreter.

Although a preferred information client is a web browser, the inventioncan be practiced with other information clients capable of (1)initiating communications with the information server 20, (2) requestingand receiving from the information server 20 an applet, and (3) defininga platform-independent (i.e., a hardware-independent, operatingsystem-independent and windows system independent) virtual machineenvironment within the respective client digital data processor 12, 14for execution of such an applet.

In addition to information server 20, server digital data processor 16includes command processor 25, comprising front end 25 a, interfacesection 25 b, and an object manager 25 c. Together, these transferinformation between the network 18 and process control apparatus 19 a-19e. As shown in the illustration, the object manager functionality isdistributed among the control stations 23 a-23 e. Each object managermaintains the data structures—to wit, objects—that control and reflectthe status of its associated process control apparatus 19 a-19 e.

The object manager 25 c provides software services for access thatpermit the creation of named objects; destruction of such objects;accessing and updating of information in the objects; the locating ofobjects within the distributed process control architecture; andnotification of changes in the information stored in objects (i.e.,event-driven notification).

As noted, the object manager 25 c allows uniquely named objects to bedistributed over the control stations 23 a-23 e in alocation-independent way. Using the object manager 25 c (via front end25 a), applets 26, 28 may create, read, write, and destroy instances ofobjects, which are subtyped into four categories: variaible—used tocontain an instance of any scalar data type (e.g., int, float, etc.) ora string; alias—used to contain a string which refers to the name ofanother object; device—used to identify a station or device in thesystem. An instance of a device type object contains no explicitstate—the name of the object is itself the state; and process—used toidentify an executing process in the system. A process object isidentical to a device object in that there is no explicit state.

As indicated above, in order to manipulate instances of objects, theobject manager 25 c provides life cycle services, access services andconnection services. Life cycle services are used to create, name, anddestroy shared objects; to register the name of process-control objects;and to find the location of any object. Access Services are used to getand set the value of one or more process-control and/or shared objects.Typically, access services are suitable for situations where a singletransfer of data is sufficient.

Connection services are also used to get and set the value of one ormore process-control and/or shared objects. However, these services aremore suited for situations where multiple transfers of data areexpected. In addition, connection services provide the ability for aclient to be continuously updated with the value of an object when itexceeds a specified delta.

The object manager 25 c relies upon the use of broadcasts over busstricture 30 in order to perform the above services. For example, whenan applet 26, 28 makes an access request on an object by name, theobject manager 25 c will broadcast the access request to all stations 23a-23 e, if the object manager 25 c does not know the location of object.Each station 23 a-23 e then determines if it is the one that hosts therequested object. Only the station that hosts the named object respondsto the request.

A preferred object manager 25 c is that commercially available from theassignee hereof, The Foxboro Company, as part of its I/A Series ofindustrial automation systems. A software interface, or “API,” of thatpreferred object manager is described in publicly availabledocumentation, including the document entitled “Object Manager Calls,” acopy of which is filed as an appendix herewith.

The command processor front end 25 a executes on server digital dataprocessor 16, configuring it to respond to requests from applets 26, 28to establish communications with them over the network 18. Oncecommunications are established, the front end 25 a responds to requestsreceived from applets 26, 28 over network 18 to transfer information toand from process control apparatus 19 a-19 e via the object manager 25c.

Particularly, the front end 25 a responds to requests received over thenetwork in TCP/IP protocol to generate calls to object manager 25 c inaccord with its aforementioned API. Moreover, the front end 25 aresponds to information generated by the object manager 25 c in responseto those calls by transmitting that information back over the network18, in accord with the TCP/IP protocol, to the applets 26, 28. In apreferred embodiment, the front end 25 a presents a simplified interfaceto the object manager 25 c, e.g., permitting applets 26, 28 to makerequests and receive responses in the form of text strings, as discussedbelow.

Software implementing a preferred front end 25 a as a Java programminglanguage application is filed as appendix hereto. Those skilled in theart will appreciate that alternate embodiments may implement the frontend in other programming languages suitable for, or that can be adaptedto, provide an interface between the network 18 protocol and the objectmanager 25 c.

Interface section 25 b provides a software interface between the frontend 25 a and the object manager 25 c. As noted above, in a preferredembodiment, the front end 25 a is implemented as a Java programminglanguage application. The object manager 25 c, on the other hand, isimplemented as a C programming language application and, accordingly,its API includes pointer-based parameters. The interface section 25 bcompensates for the inability of the Java front end 25 a to utilizepointer-based parameters, e.g., by converting them to arrays asdiscussed further below.

Software implementing a preferred interface section 25 b in the Cprogramming language is filed as appendix hereto. Those skilled in theart will appreciate that interface section 25 b is optional and may beexcluded in embodiments where the front end 25 a can make calls directlyto the object manager 25 c.

The client digital data processors 12, 14 execute applets 26, 28 withinthe virtual machine environments defined by the information clients 22,24. Each applet 26, 28 configures its respective client digital dataprocessors as a process controller that establishes communications overthe network 18 with the command processor front end 25 a and thatmonitors and/or controls the process control apparatus 19 a-19 e viathose communications. More particularly, the process controllersgenerate and transfer requests for service over the network 18 to thecommand processor 25 so as to effect the transfer of informationcontrolling, and reflecting the status of, the process control apparatus19 a-19 e. The process controllers also receive information from thecommand processor 25, e.g., for display to an operator.

As noted above, the applets 26, 28 comprise intermediate or executablecode that is interpreted or executed with in the virtual machineenvironment defined by the information clients and that ishardware-independent, operating system-independent and windowssystem-independent. Source code for preferred applets, in the SunMicroSystems Java programming language, is provided in the appendixfiled herewith.

A process control system constructed and operated in accord with system10 of FIG. 1 can be employed in a wide variety of process controlembodiments. One such embodiment is shown in FIG. 2 and described below.That embodiment provides for generation, by an applet executing on theclient digital data processor, of graphs showing trends in data valuesof process control apparatus coupled to a server digital data processor.

FIG. 2 is an event trace diagram depicting messages that flow among thecomponents of the system 10 of FIG. 1 in the above-mentioned embodiment.The components of the system 10 are shown in the event trace diagram asvertical lines with the name of the component at the bottom of the line.Messages are represented by arrows. Each message flows in the directionof the arrow from component to component. Messages that happen earlierin time are toward the top of the diagram.

Referring to FIG. 2, communication begins with the operator signallingthe information client 22 to establish communications with the serverdigital data processor 16 over the network 18. The operator can signalthe information client, e.g., a keyboard stroke or “mouse” click on theoperator console (not shown). In the illustrated embodiment, theinformation client 22 is the Netscape web browser.

In response the operator's request, the information client 22 generatesand transmits over network 18 a request for connection with informationserver 20, e.g., an HTTP server, executing on server digital dataprocessor 16. Once the connection is established, the HTTP server 20sends to the web browser 22 an HTML page that references (i.e., providesan address for) a trend-graphing applet. The HTML page also optionallyincludes text and graphics describing the applet.

The web browser 22 displays the HTML on the operator console. If theoperator signals the web browser 22 that he or she wishes to access theapplet, the web browser 22 transmits to the HTTP server 20 over thenetwork 18 a request for the applet. It will be appreciated that theapplet may be transmitted to the web browser 22, along with an initialHTML document.

The HTTP server 20 responds to such a request for forwarding Javabytecode for the applet over the network 18 to the web browser 22. Onreceipt of the applet, the JAVA-compatible web browser 22 executes theapplet 26 in the virtual machine environment defined in the web browser22.

Once executing, the applet 26 sends a request to establish a separatecommunications link over the network 18 with the command processor frontend 25 a, e.g., a Java application executing on the server digital dataprocessor 16. This separate connection is used by the applet 26 and thefront end 25 a to permit the exchange messages over the network and,particularly, to permit the applet 26 to make requests of the commandprocessor 25 for process control apparatus data to be graphed.

Once communications are established, the applet 26, 28 generates adisplay on the operator console of the client digital data processor 12and permits the operator to enter the names of process control apparatusdata values (i.e., “points”) that are to be graphed. On the operator'scommand, the applet 26 sends a request over the network 18 to the frontend 25 a specifying the OMOPEN service and listing the names ofoperator-specified points. The request is in text or ASCII format, e.g.,“OMOPEN name1; name2; name3; etc.”

On receipt of the OMOPEN request, the front end 25 a creates a datastructure required by object manager 25 c, to with an OM list, andincludes in that data structure the names of the specified points. Thefront end 25 a then makes an “omopen list” call to the object manager 25c utilizing the aforementioned API. A further understanding of the OMlist data structure and of the “omopen list” call, as well as the otherdata strictures and calls to the object manager 25 c, may be attained byreference to the appendix filed herewith.

The object manager 25 c responds to the omopen list call by querying therespective process control apparatus 19 a-19 e for current data valuesfor the points. The object manager 25 c returns those data values to thefront end 25 a which, in turn, generates and transmits to the applet 26,28 a text message listing the initial data points. That message includesthe keyword OMUPDATE, followed by the names and values of each of thepoints, e.g., “OMUPDATE point1=value; point2=value; etc.” The applet 26,28 graphs those initial data points on the operator console.

The object manager 25 c then begins looping, while awaiting furtherrequests from the client applet 26 and while awaiting updates on thedata values from the object manager 25 c. When such an update isreceived, the front end 25 a generates and transmits to the applet 26 afurther text message in the form “OMUPDATE point1=value; point2=value;etc.” listing the updated data values points. The applet 26 graphs thoseinitial data points on the operator console at the end of the graph timeinterval.

The front end 25 a continues looping and forwarding updates until theoperator signals the applet 26 to stop trend graphing. In that event,the applet 26 sends a close request over the network to the front end 25a in the form of a text message “OMCLOSE.” On receipt of that request,the front end 25 a, in turn, makes an omclose list call to the objectmanager 25 c in accord with the aforementioned API. When that callreturns, front end 25 a sends an “OMCLOSEOK” text message to the applet,26 causing it to clear the trend graph.

At this point, the operator can either specify new points to the applet26 or can tell the web browser 22, 24 to connect to a differentinformation server. If the operator signals that he or she wishes toconnect to another server, the client applet 26 breaks the connectionwith the server by sending an “OMBREAK” message to the front end 25 aover the network. The front end 25 a than resets, and waits for the nextconnection.

In a preferred embodiment, the method illustrated in FIG. 2 isimplemented in the Java programming language. As those skilled in theart will appreciate and as discussed above, all Java applets and Javaapplications run inside of a Java Virtual Machine. All implementationsof the Java Virtual Machine are guarantied to be identical regardless ofthe many hardware platforms on which they run.

The above-described trend-graphing client Java applet preferably runs inthe Java Virtual Machine that is implemented by Netscape Navigatorversion 2.02. The trend client applet 26 is intended to be portable. Soit only uses those classes that are present in all implementations ofthe Java systems. The trend-graphing applet 26 uses Java system classesto manage the screen, and connect to the trend server, and providetiming intervals.

The trend-graphing applet 26 implements classes that conduct alloperator interaction. For example, it accept the names of the points tobe graphed. It also defines the GUI buttons used by the operator tosignal when graphing is to start or stop. Further, the trend-graphingapplet 26 plots X-Y axes, graph the points, and parses messages from thefront end 25 a.

The applet 26 also processes the following messages from the server:“OMUPDATE name2=value; name3=value; . . . ”; OMCLOSEOK.

The illustrated front end 25 (or “trend-graphing server”) is notportable to just any Java Virtual Machine because it must call outsideof the Java environment to the object manager 25 c. To do this, thetrend server class is defined to have “native methods”. A “nativemethod” is any member function of a class that is implemented in alanguage other than Java. A native method can enable access to functionsand data that are “native” to a particular hardware platform operatingsystem or a running application (like the object manager 25 c).

Native member functions are declared in the class as native. They areimplemented in a library that is loaded by the Java environment atruntime. On Solaris this is a libfile.so file. On Windows NT this wouldbe a library.dbl file. The native methods, which constitute theinterface 25 b, are defined to create a new OM list, add a named pointto the list, open the list, check the list for updates (using dqchange),and close the list. Source code for a preferred implementation of nativemethods is supplied in the appendix filed herewith.

The command processor front end 25 a runs in a Solaris implementation ofthe Java Virtual Machine. The front end 25 a processes the followingmessages from the applet 26: “OMOPEN name1; name2; name3; . . . ” (inresponse to which it creates a list with the specified points and opensthe list): “OMCLOSE” (in response to which it closes the list); and“OMBREAK” (in response to which reset and wait to accept a newconnection).

Described above and illustrated in the drawings are improved methods andapparatus for process control. Those skilled in the art will appreciatethat the embodiments discussed above and shown in the claims are merelyillustrative and that other embodiments incorporating modificationswithin the reach of one of ordinary skill in the art fall within thescope of the invention, of which we claim:

1-48. (canceled)
 49. A digital data processor for use in a controlsystem that includes a control apparatus that has one or morecontrol/sensing devices, the digital data processor executing a programreceived by it over an internet protocol (IP) network, the programconfiguring the digital data processor to receive, via the IP network,information associated with the control apparatus, where thatinformation does not comprise, nor is it received within, a web page.50. The digital data processor of claim 49, where the program configuresthe digital data processor to receive the information from the IPnetwork in a text form.
 51. The digital data processor of claim 49,where the program configures the digital data processor to exchangemessages over the IP network in text form for purposes of at least oneof monitoring and controlling the control apparatus.
 52. The digitaldata processor of claim 49, where the program configures the digitaldata processor to generate requests for information associated with thecontrol apparatus.
 53. The digital data processor of claim 52, where theprogram configures the digital data processor to generate the requestsfor transmission on the IP network in a text form.
 54. The digital dataprocessor of claim 53, where the program configures the digital dataprocessor to generate the requests and to receive the information inorder to monitor the control apparatus.
 55. The digital data processorof claim 53, where program configures the digital data processor togenerate the requests and to receive the information in order to controlthe control apparatus.
 56. The digital data processor of claim 49, wherethe information comprises a process variable associated with the controlapparatus.
 57. The digital data processor of claim 49, wherein thedigital data processor receives the program from a server that iscoupled to the IP network.
 58. The digital data processor of claim 57,wherein the server is associated with the control apparatus and whereinthe interface executes at least in part on the server.
 59. A controlsystem, comprising A. a digital data processor in communication couplingwith a control apparatus via an internet protocol (IP) network, thecontrol apparatus comprising one or more control/sensing devices tomonitor and/or control a process, and B. the digital data processorexecuting a program received by it over the IP network from a serverassociated with the control apparatus, the program configuring thedigital data processor to receive, via the IP network, informationassociated with the control apparatus, where that information does notcomprise, nor is it received within, a web page, C. where the programconfigures the digital data processor to receive the information fromthe IP network in a text form, D. n interface that is coupled to thecontrol apparatus and to the digital data processor, the interfacegenerating said information in response to a request generated by theprogram.
 60. The control system of claim 59, where the interfacegenerates the information in a text form.
 61. The control system ofclaim 59, wherein the interface executes at least in part on a server.62. The control system of claim 59, wherein the program comprises aprogram that executes in a web browser.
 63. The control system of claim59, wherein the program configures the digital data processor togenerate, as at least one of the requests, a request for a processvariable associated with the control apparatus.
 64. A control system,comprising A. a control apparatus comprising one or more control/sensingdevices to monitor and/or control a process, B. a digital data processorexecuting a program within a web browser, the program (i) configuringthe digital data processor for monitoring the control apparatus, (ii)generating a request for information associated with the controlapparatus, C. an interface in communication with the control apparatusand with the digital data processor, the interface responding to therequest for transmitting information associated with the controlapparatus, where that information does not comprise, nor is it receivedwithin, a web page.
 65. A control system, comprising A. a controlapparatus comprising one or more control/sensing devices, B. a serverdigital data processor that is coupled to the control apparatus, C. aclient digital data processor in communication coupling with the controlapparatus and with the server digital data processor, D. the clientdigital data processor executing a program that configures the clientdigital data processor for monitoring the control apparatus, the programcomprising any of (i) a JAVA applet, (ii) an intermediate languageprogram, (iii) a byte code program, (iv) a downloaded program thatexecutes in a virtual machine environment, (v) a program that executesin a web browser, E. at least one of the control apparatus and theserver digital data processor (i) having an object that stores a datavalue associated with the control apparatus, and (ii) responding to arequest for that object by transmitting to the client digital dataprocessor the data value, where the data value is transmitted other thanas or within a web page.
 66. The control system of claim 65, where thedata value is transmitted in a text form.
 67. The control system ofclaim 65, wherein the transmitted data value represents a processvariable associated with the control apparatus.
 68. A portable wirelessdevice for use in a control system that includes one or morecontrol/sensing devices, the portable wireless device executing aprogram received by it over an internet protocol (IP) network from aserver associated with the control apparatus, the program configuringthe portable wireless device to receive, via the IP network, informationassociated with the control apparatus, where that information does notcomprise, nor is it received within, a web page.
 69. The portablewireless device of claim 68 adapted for use in a control system in whichthe process control apparatus includes said one or more control/sensingdevices to monitor and/or control a process.